Draft docs for the clearinghouse, for review @ John. Two pages:

docs/run-a-job.md — Tier 1, the consume path

The developer flow: find an app → call it through the SDK → pay via a signer.

• Frames apps as containers orchestrators host, with passthrough over HTTP / SSE / WebSocket / trickle; runtime in beta (contact the team to onboard your own app).
• Discovery via the dashboard or the discovery endpoint, routed by app id.
• One worked example per transport, grounded in the real livepeer-python-gateway SDK and the example apps: hello-world (HTTP), vllm (SSE), echo (trickle), streaming-asr (WebSocket).
• Payment via a hosted signer (PymtHouse) with a pointer into the Payment Provider doc.

docs/payment-provider.md — Tier 2, the operator role

• Payments on Livepeer — PM tickets settle in ETH; a signer mints them so your app pays with just a URL + key.
• Three paths: use a hosted signer (fiat billing, no crypto), run a remote signer (next to your SDK on a private network, no accounts), run the clearinghouse suite (auth/metering/billing via OpenMeter, OAuth, Stripe — ports & adapters).
• Reference: signer flags, endpoints/status codes, auth-webhook contract, create_signed_ticket event.

Open questions for John

• Does the framing of the lean clearinghouse core + suite match your build plan?
• *(In build)* markers flag what's still scaffolded in livepeer/clearinghouse — correct as listed?
• Is https://pymthouse.com / https://api.pymthouse.com the right hosted endpoint to point developers at?

Status: draft. Code samples are illustrative of the target DX; SDK method/param names may still change.

🤖 Generated with Claude Code

Refs #16